In accordance with recent technical developments, various types of personal computers (PCs), such as desktop and notebook computers, are being produced and sold. When shipped, the PCs may be equipped only with basic devices, such as CPUs and main memories, installed as standard features, but thereafter, end users can expand their capabilities by adding peripheral devices upon their individual needs. Generally, such a PC executes various computer processes under the control of basic software called an operating system (OS).
Conventionally, one can expand the capability of a PC by inserting a peripheral device called an "expansion adaptor card" into a bus slot that is provided on the PC (see FIG. 7(a)). Video adaptors, communication adaptors, expansion memories, SCSIs (Small Computer System Interfaces) are example of expansion adaptor cards.
The use of expansion adaptor cards to expand the system configurations has been especially effective for desktop computers. However, as notebook computers are designed to be small and compact, the attachment density in their main bodies is very high, and the number of bus slots provided and the space available for media storage are extremely limited. In other words, the possible expansion of the system configuration of a notebook computer by using an expansion adaptor card is limited.
A so-called PC card is a peripheral device, the size of a credit card, that has been developed to compensate for the limited configuration expansion of notebook computers. If a slot (a PC card slot) having a storage space for storing a PC card and a connector for electric connection to the PC card is provided in a notebook computer, the system configuration of the notebook computer is easily expanded (see FIG. 7(b)). The international standard guidelines concerning the mechanical and electric specifications for PC cards are determined by PCMCIA (Personal Computer Memory Card International Association) and JEIDA (Japan Electronic Industry Development Association). At present, three types of PC cards are being shipped: Type I, which is 3.3 mm thick; Type II, which is 5.5 mm thick; and Type III, which is 10.5 mm thick. Type I is used mainly as a memory card. Type II is employed for the use as a facsimile/modem, an Ethernet adaptor, and a SCSI adaptor. Type III is used mainly as a hard disk incorporated card. Recently, since the selection of available PC cards is larger and their prices are lower, PC card slots are not only being provided for notebook computers but also for desktop computers. Following the U.S. government announcement that one of its procurement standards is "the equipping of all desktop computers with PC card slots", the spread of PC cards has accelerated.
The main feature of PC cards is that they can be frequently inserted into and removed from the system. This feature is important for the following reasons: the needs of users vary; the required devices for portable PCs, such as notebook computers, change in accordance with the locations in which they are used; the number of card slots with which a PC can be equipped is limited. The original premise on which the design of PC cards is based is that the cards would not be fixed to the main body of a PC like an expansion adaptor. A form factor, in this case, is that the shape and the design of a cartridge are based on the ease with which the cartridge can be attached/detached. PC cards can also be actively inserted/removed (hot-plugged in/out).
When a system configuration is changed due to the inserting/removing of a PC card, the PC main body (hereinafter also referred to as a "system") must re-allocate system resources. The system resources here are, for example, I/O addresses, memory addresses, DMA (Direct Memory Access) channels, and IRQ (Interrupt request) channels. A CPU accesses a peripheral device in accordance with the I/O addresses assigned to it. A peripheral device can issue a request or transmit responses to the CPU in accordance with the DMA channel or the IRQ channel that are reserved for it. The host PC, therefore, must so allocate its system resources that no resource conflicts arise among the peripheral devices. Since the system resources are limited (for example, for an ISA (Industry Standard Architecture) system, only eight DMA channels and 16 IRQ channels are provided), they should be distributed effectively. For example, a system resource allocated for a peripheral device that has been removed and is no longer a part of the system configuration should be promptly released, and an IRQ channel should not be reserved for a peripheral device that does not use one any more. In order to effectively utilize PC cards, re-allocation of system resources must be dynamically and efficiently performed.
Conventional peripheral device employ jumper or DIP switches to define the system resources that it uses. Since common users find it difficult to manipulate jumper or DIP switches without causing system resource conflicts among peripheral devices, Microsoft Corp. and Intel Corp. have developed the "Plug&Play" specification (hereinafter referred to as "PnP") for automatically altering system environments, including the allocation of system resources, in accordance with the plugging in and the plugging out of peripheral devices. With PnP, even when a peripheral device is actively inserted or removed while a system is in operation, the system resources are dynamically allocated or are released, and when a system resource conflict arises, it is automatically resolved. In other words, with PnP, the system performs peripheral device setups which user had done manually.
Among the interfaces used by PC, the standardized specification for the PC card, that was developed by PCMCIA/JEIDA, supported PnP from earlier time. When a PC card is inserted into a system, the system automatically recognizes the PC card, and PC card software ("Card Service" and "Socket Service" that will be described later) automatically assigns system resources to the PC card and configures it for the system. As a result, neither jumper nor DIP switches are required for PC cards.
The PnP mechanism for a PC card will now be described while referring to FIG. 8.
In the DOS (Disk Operating System; Windows 3.1 is included, the reference hereinafter being expressed as "DOS/Windows 3.x") environment, the PC card PnP is implemented with the help of two kind of device drivers for PC cards. One is a "Socket Service", and another is "Card Service". The Socket Service and the Card Service constitute important software layers by which DOS can identify PC cards. These layers are required for all types of PC cards. In the upper of the two software layers is a individual device driver (client driver) for a PC card required for the driving of the corresponding PC card.
The Socket Service is a software layer for providing an abstract representation of a hardware PC card controller, and includes a function call for directly controlling the PC card controller. The upper software layer can communicate with the hardware via the Socket Service.
The Card Service is a software layer for managing the system resources of a PC card inserted into a card slot. The Card Service includes a function call for the Socket Service and provides a programming interface (PI) for the upper device driver (client device driver) registered as a client in the Card Service.
The client device driver is a device driver for a individual PC card, i.e., a dedicated device driver prepared only for a corresponding PC card. Example client device drivers are a LAN card driver for a LAN card, a memory card driver for a memory card, and a SCSI card driver for a SCSI card. By performing client registration to the Card Service, these client device drivers can be informed of an event, such as the insertion and removal of a PC card, and can also request the Card Service allocate/release system resources, and start/stop the power supply to the corresponding PC card. It should be noted that, in order to support the PnP function, the client device driver should be loaded by the system in advance and registered as a client in the card service.
When, for example, a PC card is inserted into a slot in the DOS/Windows 3.x environment, the Socket Service and the Card Service identify the card insertion event through the PC card controller. Then, the Card Service reports the event to the client device drivers that are registered as a client of the Card Service (arrow P1 in FIG. 8). Upon the receipt of the notification of the event, the client device drivers sequentially read attribute information (also called a tuple) from the memory in the PC card (arrows P2 and P3 in FIG. 8). A client device driver, which ascertains by referring to the tuple that it is the driver corresponding to the inserted PC card, learns, from the contents of the tuple, the system configuration required for the PC card, and forwards a request to the Card Service for the assignment of a system resource (arrow P4). When the Card Service finds an available system resource, writes it into a resource table in the Card Service, and permits the client device driver to use the system resource (arrow P5). Then, the client device driver programs the PC card controller via the Card Service and the Socket Service (arrow P6), and install the PC card in the system configuration. The client device driver then requests the PC card controller to power the slot. As a result, the PC card is activated as part of the system.
The Socket Service and the Card Service are already standardized by the PCMCIA following the Rel 2.1 (or the JEIDA following the Ver 4.2). The Socket Service and the Card Service, which may be regarded as device drivers for a PC card slot, are software for accessing a PC card slot. It should be noted that PC card control software, such as the Socket Service and the Card Service, are not standard features of conventional DOS. Therefore, generally, these two device driver layers are provided by PC card software makers other than the makers of OSs. For example, "PlayAtWill" ("PlayAtWill" is a trademark of IBM Corp.), sold by IBM Japan, Ltd., is a software product package that includes the Socket Service and the Card Service.
An operating system (OS) is, as is known, basic software for the general management of PC hardware and software. In general, an OS includes a "file manager", for managing the writing and the reading of files relative to an auxiliary storage device, such as a hard disk drive (HDD); a "memory manager", for managing memory space; and a "scheduler", for managing task execution priorities. In addition, included in an OS is a "user interface" for handling a screen display, command input and the operation of a mouse.
One example of a recent OS is "Windows 95", released by MicroSoft Corp. in 1995. Windows 95 is a "32-bit OS" that can operate in a 32-bit address space provided by a CPU having a 32-bit architecture (e.g., 80486SX by Intel Corp. or higher). The conventional DOS/Windows 3.x is a "16-bit OS" that operates in a 16-bit address space provided by a CPU having a 16-bit architecture (e.g., 80386 by Intel Corp.). Windows 95 is a high-performance OS that can fetch and process data for the CPU twice as fast as the DOS/Windows 3.x. Windows 95 also includes a 16-bit compatible mode in order to ensure compatibility with applications prepared for DOS/Windows 3.x. It should be noted, however, that when operating in the 16-bit compatible mode, since the 16-bit mode and the 32-bit mode are switched as necessary in the kernel (core) of the OS, the performance is inevitably reduced.
In one aspect, Windows 95 is designed for the integration of information processing apparatus (OA apparatus, communication apparatus, etc.). "Multitasking support" and "PnP support" is its main features. Windows 95 is designed to provide multitasking support because the parallel processing of a plurality of operations is the key to the connecting of information processors (for example, a telephone call or a facsimile communication can be accepted during the reproduction of a picture image, or an e-mail can be read on a display screen in the foreground while the database of a server is being accessed in the background). Further, Windows 95 is designed to provide PnP support because this reduces the cost of running a PC in the office. Since a greater variety of peripheral devices can be attached to a PC, and since the system configuration, although more complicated, is managed automatically, the running costs are reduced and the integration of a number of different types of information processing apparatuses can be performed.
In FIG. 9 is the PnP architecture of Windows 95. As is shown in FIG. 9, in Windows 95 a bus enumerator is provided for respective sub-systems (e.g., an ISA bus, a PCI (Peripheral Component Interconnect) bus, a SCSI (Small Computer System Interface) bus, and a PCMCIA bus), and a software layer called a "configuration manager" is provided at the upper level of the bus enumerators. For example, a PCMCIA bus enumerator includes a Socket Service and a Card Service that conform to the PCMCIA Rel 2.1, a common enabler for enabling a PC card, a device driver loader for automatically loading a client device driver, and a C/M interface for interacting with the configuration manager.
As there are many types of device drivers present in the OS, the system will not operate effectively in case resource conflicts arise among these drivers. In Windows 95, cooperation between the device drivers assigned to the separate buses is provided by using the bus enumerators, and the configuration manager manages the resources for the entire system. The PnP support is thus implemented. When, for example, a PC card is inserted into the card slot, first, the PC card is automatically identified locally via the PCMCIA bus enumerator, and system resources are assigned by the configuration manager so that they do not conflict with the other resources assigned to peripheral devices on the other buses. In this manner, the PC card is added to the configuration system.
In addition, the PnP function in Windows 95 not only performs the dynamic configuration of system resources but also performs the automatic loading of device drivers. For example, when a PC card is inserted into the system, the PCMCIA bus enumerator assigns a system resource to the PC card, and automatically loads an appropriate PC card device driver (client driver). This differs from the function provided by DOS/Windows 3.x, which is based on the client driver always being resident in the memory, and has the effect of reducing the memory space permitted for device drivers.
The PCMCIA/JEIDA, which are the PC card standardization associations, are preparing specifications that would keep up with the progress attained by host systems. The "PC card standard" released in 1995, for example, includes the "CardBus", which has a 32-bit bus master function for supporting a high-speed PCI (Peripheral Component Interconnect) bus. With the CardBus, a multimedia function, such as the fetching of high quality picture images, can be accomplished by a PC card.
On the other hand, multitasking and PnP support for the OS also have been studied with the primary aim being the integration of information processing apparatus. In Windows 95, the OS voluntarily manages hardware resources, and the Socket Service and the Card Service for automatically identifying PC cards, for example, are provided as standard features in Windows 95.
PC cards and OSs, however, are not always synchronously developed. This occurs for the simple reason that specifications for PC cards are standardized by the PCMCIA/JEIDA and the cards are developed by PC card venders, while OSs are developed by OS makers, such as Microsoft Corp. That is, the PC cards and the OSs are developed independently. A more specific example is the support provided for the "CardBus". Although Windows 95 was released in 1995 and its PCMCIA function, i.e. the Socket Service and Card Service attached thereto, is 32 bits wide, it just conforms to "PCMCIA Rel 2.1" (a specification issued for the prior generation) which was issued in 1993. More time will be required for the PCMCIA function of Windows 95 to be updated so that it conforms to the latest "CardBus" specification. On the other hand, in 1996 PC card makers shipped PC cards and device drivers that support CardBus, and this year PC makers also plan to ship PCs that are equipped to handle CardBus. But the CardBus device drivers that are supplied by PC card makers are generally still for 16 bits, and can not be used in the 32-bit mode of Windows 95. The CardBus device drivers are designed as 16-bit drivers, while Windows 95 does not support CardBus.
That is, a paradox situation has arisen because Windows 95 native mode device drivers can not handle PC cards conforming to the latest PCMCIA/JEIDA specification even though they are 32-bit, high-performance device drivers, while the device drivers supplied by PC card makers are only 16-bit drivers, i.e., for use in DOS/Windows 3.x, even though they can handle the latest type PC cards.
Thus, PC cards that support Cardbus can not be used in the Windows 95 native mode. If a user desires to use a CardBus PC card, he or she has no choice but to employ a 16-bit device driver intended for DOS/Windows 3.x. However, in Windows 95 a 32-bit mode and a 16-bit mode are mutually exclusive. When a PC card is to be used in a 16-bit mode, a corresponding 32-bit sub-system (a PCMCIA bus enumerator) must be disabled in turn. In addition, since the switching between the 32-bit mode and the 16-bit mode is not a dynamic process but a static one, if the 32-bit mode can not be enabled during the operation if it is disabled at the time of OS boot sequence.
The employment of a PC card in the Windows 95 native mode is accompanied by the following problems.
(1) Before a CardBus PC card is used, a Cardbus driver for DOS/Windows 3.x (a 16-bit driver) must be loaded into the system and a PCMCIA bus enumerator (a 32-bit driver) must be disabled in turn. In this case, Windows 95 native mode device drivers can not be used at all. In this context, when a PC card for Windows 95 is inserted into the system, either it must be driven by a 16-bit driver for DOS/Windows 3.x, or it can not be driven at all. As a result, the advantages available with the Windows 95 native mode drivers, such as the automatic loading of client drivers, can not be utilized.
(2) As a result of a sub-system in Windows 95 being operated in the 16-bit mode, 32 bits and 16 bits switching is constantly performed in the kernel of the OS, and the performance of the entire system is always lowered.
(3) When a CardBus PC card is inserted into the system while the PCMCIA bus enumerator (a 32-bit driver) is being enabled, a corresponding device driver (a 16-bit driver other than that of Windows 95) can not be used in turn, and the PC card can not be operated. In other words, it may happen that the insertion of a different PC card version is limited at times. This greatly deteriorates the PnP function of the PC card. The usability of an apparatus, such as a notebook computer for which dynamic configuration of the system resource is required, is lost.
There are other conventional PC cards that can not be driven by Windows 95 native mode drivers because the PC cards conform to an older PCMCIA/JEIDA version. A user who owns such a conventional product has no choice but to employ a conventional device driver intended for DOS/Windows 3.x, and will also encounter the above problems.
(1) For client registration, the Card Service registers an entry point (i.e., a common address at which an event record is to be transmitted to a client) at which a callback routine is entered relative to a client driver.
(2) The PCMCIA bus enumerator in Windows 95 provides a programming interface (PI) between the Socket Service and the other portions. Therefore, the other PC card makers can replace the native Socket Service of Windows 95 with their own Socket Services.
(3) "PCMCIA Rel 2.1/JEIDA Ver 4.2", that is the PC card specification prescribed in 1993, specifies card attribute information (CIS), a Card Service, a Socket Service and an interface. The "PC card standard", that is the PC card specification prescribed in 1995, upgrades the conventional specifications and also describes CardBus, a power management specification, and a multi-function.
It is, therefore, one object of the present invention to provide a superior method for automatically enabling a peripheral device, which can be applied to an information processing system that has both a peripheral device driven by a device driver in a first addressing mode and a peripheral device driven by a device driver in a second addressing mode, whereby a peripheral device can be enabled and driven by an appropriate device driver.
It is another object of the present invention to provide a superior method for automatically enabling a PC card, which can be applied to an information processing system that has a PC card driven by a 16-bit device driver and a PC card driven by a 32-bit device driver, whereby a PC card can be enabled and driven by an appropriate device driver.
It is an additional object of the present invention to provide a superior method for automatically enabling a PC card whereby, when a PC card that can be driven only by a DOS/Windows 3.x device driver is inserted, the PC card is enabled by that device driver, and whereby, when a PC card is inserted that can be driven by a Windows 95 native mode device driver, the PC card is enabled by that device driver.
It is a further object of the present invention to provide a superior method for automatically enabling a PC card whereby a sub-system in Windows 95, e.g., a PCMCIA sub-system, can, in appearance, be dynamically switched between a 32-bit mode and a 16-bit mode.